Epics Tools Enhancements and Transportability

The Jefferson Laboratory electron accelerator is controlled by the Experimental Physics and Industrial Control System (EPICS), which was initially developed by the Los Alamos and Argonne National Laboratories, and which has since become an extensive collaboration among scientific institutions worldwide. In keeping with the spirit of cooperation and exchange fostered by the EPICS community, the Controls Software group at Jefferson Laboratory aims to produce portable software tools useful not only locally, but also at any EPICS site, and even at non-EPICS sites where feasible. To achieve this goal, the group practices several software engineering principles which have demonstrated success in producing sharable software. This paper first discusses those principles along with the practicalities involved in pursuing them, and then illustrates how they prevail within three different frameworks: the architecture and operating system (OS) portability provided by the EPICS environment, which assists in porting to other EPICS sites; the control system portability inherent in the Common Device (CDEV) abstraction layer, which facilitates porting to any supported control system; and the general system portability which follows from careful code design. 1 GENERAL CONSIDERATIONS Because a control system is, by intent, uniquely customized to perform site-specific tasks, designing control system software for effective use at various unrelated sites might seem, at first, to require an amount of work disproportionate to the rewards such an endeavor might garner: not only must the programmer attempting do so solve the immediate problem which necessitates his application, but he must also devise some technique for dealing with the differences which arise among sites. Furthermore, he must decide how portable his application really can and should be before beginning to work on it. Fortunately, these latter quandaries are substantially mitigated by the nature of the undertaking in question. It may be of a sort which is “algorithmically” portable from one site of a particular type, to another of the same type. Two particle accelerators, for example, might require software to measure and tune the phase of an RF cavity. While these sites may not use the same control system, the general solution to their common problem may be sufficiently parameterizable such that the same program could be used at both, if it were capable of controlling each system in the same generic way. Work supported by the U.S. Department of Energy, contract DEAC05-84ER40150 y Email: [email protected] Another type of inherently portable application is the sort which provides basic facilities closely tied to the system being controlled. Examples include data acquisition, logging, and retrieval systems, human interfaces for monitoring and managing the underlying physical system, and utilities for measuring and analyzing the system in a userspecified manner. Such tools are fairly useful in a general sense across control systems and physical machines, so that for every site to design its own set seems tantamount to “reinventing the wheel”. Ideally, the site-specific information should be configured via some localization method. Of course, there are good and bad reasons for one site to avoid reusing software from another. In order to create a general purpose tool which another site will want to use, the designer must in some way address both. Among the former category are considerations arising from concern over efficiency and compatibility. Does the application make assumptions about the underlying system such that it works well in one situation but not in another? If it generates output data, will it do so in a format which other tools can read? Notorious among the bad reasons is reluctance arising from the well-known “not developed here” syndrome, a psychological phenomenon pervasive in the engineering world. It derives, perhaps, from the fear of becoming dependent upon the work of someone whose interests may not necessarily coincide with one’s own. This leads to a consideration of those factors which might induce a developer to produce code specifically designed only for local use. The benefit of such an approach is that it may allow for a tight integration among the tools in a local suite: if an application can make assumptions about the existence of other facilities, it can incorporate their features, providing users with multiple points of entry to the various system tools. Additionally, designing for a known system allows for faster development –because the programmer knows exactly the environment in which his application will run, he can avoid having to handle certain special exceptions which might arise from one site to another. Furthermore, a small user base will likely limit requirements and feature creep. Note, however, that these assumptions about the environment imply that the benefits pertain only if the situation for which the application is written persists over time. What happens if something about it changes? What if one of the subsystems upon which the code depends is removed, or, more drastically, if the control system changes (not so preposterous: the CEBAF accelerator was switched from TACL[1] to EPICS during the commissioning of the machine in the mid ’90s). The programmer can ameliorate the problems arising from such occurrences by designing his application to be portable from the outset. Fundamentally, * 0-7803-5573-3/99/$10.00@1999 IEEE. 741 Proceedings of the 1999 Particle Accelerator Conference, New York, 1999